IBIS Macromodel Task Group Meeting date: 17 October 2017 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Bob Ross to send out his proposed no-pin-duplication rules for BIRD189. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD158 Ts4file (Touchstone) file contents (email question from Michael Mirmak): - Arpad: Michael asked if other types (G, H, Y, or Z parameters) are also allowed? - Walter: It can be anything. Anything can be converted to S-parameters. It's simply a Touchstone file, it's not restricted to S-parameter data. - The answer to Michael's other question is: - It must be an s4p (exactly 4 ports). - Arpad: Yes, if you allowed more than 4 then you'd have to deal with terminating the extra ports, etc. - Walter: Agreed, why complicate it? - Walter: I also commented in my reply that we haven't traditionally had ibischk verify the correct number of terminals or ports elsewhere. For example, I don't think ibischk verifies the terminal count of an IBIS-ISS subcircuit, etc., included in an [External Model]. - We haven't done it before, but it's a fair question to ask if we should. - Mike L: I think the rule we've used before is that we only write checkers for files whose format we specify. - Walter: We specify the contents of Touchstone and IBIS-ISS files. - A Ts4file is a Touchstone file with 4 ports. - We could check and make sure it has 4 ports. Is it worth it? - Arpad: It might be a convenience feature, but seems unnecessary. - Walter: Agreed. If we did it would it complicate ibischk, and would it be worth the cost to develop it? - Mike L: Someone mentioned that Brian Anderson, who wrote the tschk2 parser, is no longer at Keysight (Agilent). He's not available to work on it anymore. We got one code dump from him and have never really changed it. - Radek pointed out that various EDA vendors have their own parsers already. - So it's unlikely any new tschk would be adopted the way ibischk is as a front end for some tools. - So getting people to voluntarily pay for the tschk is unlikely. - If we did want ibischk to do some checking on the Ts4file, it should be minimal port checking but not actually parse it. - Walter: side note: - I think Touchstone 2.0 was a major mistake. - What the industry wanted was Touchstone 1.0 plus per port impedance. That's it. - As long as you didn't have the new keyword, then all the existing parsers out there would still have worked. - Problem with Touchstone 2.0 is that it was a major rewrite of the parser you already had, even if you only wanted per port impedance. - I recommend we say 2.0 was a dead end. Go back and create a 1.1 or something that only adds per port impedance. Abandon mixed mode representations, and perhaps consider adding sparse file support and binary support (but done differently than 2.0). - Arpad: As for Michael Mirmak's questions about BIRD158: - We have answers to his questions. - Since we have a vote scheduled for the next Open Forum meeting, on the 26th, do we need to scrub BIRD158.6 and make another version BIRD158.7? - Mike L: [Sharing BIRD158.6 - searching for relevant text] - The reference to S-parameter, as opposed to Touchstone, only appears in the Background Information section, as Michael M. had mentioned in his email. - Arpad: Technically in s4p, the s is for scattering parameters. - Do people actually change the s in the filename extension if they have another type of data other than S-parameters? - Walter: I haven't seen many with anything other than S-parameters, but I've only seen s in the filename extension. It's one of the data records in the file that says what the format is. - Mike L./Arpad: "Touchstone" only appears in a few places in the BIRD, and always in the context of a file. - Arpad: Should we add a sentence saying that the Touchstone file can contain any type of data? - Mike L: It would probably only be necessary if we were excluding some type, but we aren't. - Since the "S-parameter" reference is only in the Background Information, we can probably just note the change during the vote. Someone may insist on creating a BIRD158.7. - Arpad: I would like to correct the Background Information section for the sake of history. - Walter: We could do it at the Open Forum meeting and introduce it at the vote. - I think it will just pass. - Randy: We haven't received any email pre-votes that would object to this change. - Arpad: Can Mike L. take the AR to respond to Michael M.'s question and explain our course of action? Could you also notify the Open Forum of the slight changes? - Mike L: Yes. C_comp improvements: - Mike L: These improvements are for the circuit inside the buffer. Is that why they can't be resolved simply with IBIS-ISS? - Randy: Yes, it's supposed to be a direct replacement for the C_comp element, which is in the buffer [Model]. - Mike L: Did you also potentially need an extra node, for Input buffer? - Could that be an extension of BIRD189? - Randy: It would create a node where you might have to specify it if you had changes to the Si_location or Timing_location. - Mike L: Okay, maybe there's more to it, but I was thinking we have a location Buffer_I/O in BIRD189, and maybe there could be a Buffer_I and a Buffer_O. - Arpad: That's an interesting question. With the C_comp improvement circuits, would the compensation include this or not? - If the compensation is not including these, then they could be included in the on-die portion of a BIRD189 model. - Walter: We decided that the model would still contain a legacy C_comp. This "effective" C_comp would be used by the tool to generate the K(t) tables, but then at simulation time it uses the full improved C_comp subcircuit. - Randy: Yes, that's how it's written in the BIRD draft. It may require the use of C_comp_corner to provide the effective C_comp. - Arpad: Then do we need the C_comp subcircuit if a BIRD189 model could put it in the same place? Couldn't we just put it in the BIRD189 model. - Walter: No, the V(t) curves are based on everything in the [Model] without the on-die interconnect. The [Model] has to have everything you need to generate the data. BIRD189: - Walter: We currently have two fundamental issues: - 1. If you have a pin to pad model, you don't need to also have a pad to buffer model. Bob Ross disagrees with me on this. - 2. This no-repeat rule should be limited to victim pins. - You can't have two models in the same Group that have the same I/O pin as a victim. - Arpad: I want to revisit my question about pins that are specified multiple times, but only as aggressors. - If I have 10 pins. Say 1 and 10 are aggressor only. Pins 2 through 9 are victims. - Say I have two different models for this scenario. - If the user then wants to do a single channel simulation simulating only pin 1 or pin 10, they have two choices. They have two models that list those pins as aggressors, and none that list them as victims. - Walter: If the person making the model does that and wants to make sure pins 1 and 10 are covered, then they should make another model with those as victims. - If you are simulating a particular net, maybe it should be one that's a victim. - If that net never appears as a victim, then the model maker understands there may be an ambiguity. - Discussion: Arpad suggested that we need some language in the spec to explain, clarify, or disallow this ambiguity. He noted that the point of the original discussion was to try to limit any required user selections to those made with respect to the Group keyword. We want to avoid any other ambiguity that might result in a selection. Walter said we could add language to the spec stating: - If a pin appears as a victim, then that model should be used. - If a pin only appears as an aggressor, and it appears multiple times, then there is an ambiguity if you want to simulate that pin. The model maker should not do that if they want that pin simulated without ambiguity. Arpad reiterated that this is only an issue if the user wants to perform an uncoupled single-channel simulation on a pin that has only been specified as an aggressor and has been specified in multiple models. - Arpad: We also had the questions about signal models vs PDN models. - Can we have a PDN only model with no signals? - Walter: Yes. - Randy, when you do PDN and signaling models for DIMMs, do you have coupling between them? - Micron delivers advanced power aware models to customers. - Randy: For our internal analysis at a DIMM level we use some tools that provide signal and PDN in the same model. It's not that common. - Walter: Would you deliver such models to your customers via IBIS? - Randy: I'll have to investigate and think about that. - Walter: We allow it in the BIRD189 scheme. - Arpad: This PDN vs. signal came up in the context of Bob's rules. - Walter: Say you have a package with coupling between signal and power. - You generate a big S-parameter from pin to pad with your package extraction tool, and it has coupling between I/O and power. - Then you may have a separate PDN only model from pad to buffer. - You can use them together. I think that works. You end up just having shorts between all the I/O pad and buffer terminals. - Randy: I agree. I could see myself delivering just such a model. - This is a case where you're assuming the on-die interconnect for the signals is handled with C_comp. - Walter: You couldn't have the package model go from pin to buffer in that case because you need the additional on-die PDN model to go from pad to buffer. So the package model has to go from pin to pad. -Discussion: Arpad and Walter discussed how models might be grouped in this type of scenario. Arpad asked how the model maker would organize things if the goal was to allow the user to independently choose the on-die (buffer to pad) model and the package model (pad to pin). He asked if you'd have one group to specify on-die and another to specify the package. Walter said no. Walter said the model maker would make individual Groups each containing one of the on-die models and one of the package models. Arpad said he was concerned about the number of permutations, for example 3 package options and 4 on-die PDN options would yield 12 Groups, but that he actually agreed with this approach. - Mike L.: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. AR: Mike LaBonte to notify the Open Forum about the minor edits to BIRD158.6 Background Information. ------------- Next meeting: 24 October 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives